With the advent of the Internet, sometimes referred to as the “web,” businesses and consumers have multiple means of communication not previously available, including, but not limited to, business-to-business (B2B) and business-to-consumer (B2C) links. As businesses seek to take advantage of the web, some companies have provided specific applications, called “e-business” applications, that work in that particular environment. In addition, companies, such as International Business Machines Corporation (IBM) of Armonk, N.Y., have developed products that facilitate the deployment, integration, execution and management of e-business applications. One such IBM product is “WebSphere,” which encompasses tools for developing e-business applications and middleware for running web-based applications. One part of WebSphere is a WebSphere Application Server (WAS), which is a run-time component of the WebSphere family of products. Basically, WAS is a Java process with a Java Virtual Machine (JVM).
Currently, WAS uses a Java2 security model to ensure the integrity of applications and the WebSphere runtime environment. There are two closely related problems with the Java2 security in WAS. First, Java2 imposes a significant runtime performance penalty; and, second, the process for defining precise security permissions is cumbersome. For, example, permission checking associated with these two issues imposes a twenty-two percent (22%) performance overhead running a version of “Trade3” benchmark Jave2 Platform Enterprise Edition (J2EE) application.
The Java Versioning and Modularity working group have proposed a modular approach to enhance WAS versioning and release-to-release compatibility management. The basic approach is to group Java archives (JARs) into modules with explicitly defined interfaces among modules. Each module exposes public interfaces with an explicit “EXPORT” definition. Each module also declares dependencies on other modules with an explicit “IMPORT” definition. This modular approach is in conformity with the OSGi Specifications.
Java2 security employs permission checking to enforce the access control policy. Under the standard Java2 implementation, permission checking is performed every time an interface is accessed during runtime. This is the primary source of the performance penalties of the standard Java2 security. The J2EE runtime environment default Java2 security policy allows J2EE applications a very limited set of permissions to ensure runtime integrity. When a J2EE application is deployed to a WAS runtime environment, an information technology (IT) administrator is prompted to take necessary actions if that application requires additional permissions. To determine whether additional permissions can be granted to the application requires that IT administrators have a good understanding of the implications of granting particular permissions to the application.
What is needed is a method of security protection that does not have an inverse impact on performance, i.e. does not impose the typical Java2 runtime performance penalty, and does not require a user to set a wide variety of permission settings for every class or module.